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ie INTRODUCTION 


A. BACKGROUND 

Since the first infectious and destructive computer virus was created 
in November 1983), and the first microcomputer virus in January 1986",the 
computer security field has never been the same." Computer viruses have 
received wide reporting in both trade journals and the general press. Viral 
code written in Asia could be "exported", via modem or mail, around the 


world.’ Systems could be infected quicker than warnings could be received 


5 


and precautions taken. The recent, and much publicized, UNIX Worm and 


AIDS Trojan incidents are but two examples of the damage malicious code 


can do. 


While conducting Doctoral Thesis research at the University of 
Southern California in 1983 and 1984, Fred Cohen developed the first 
computer virus and conducted propagation experiments on a VAX computer 
with a UNIX operating system. 


The virus, later named Pakistani Brain, originated in Lahore, 
Pakistan. It was developed by two brothers purportedly as a copy 
protection scheme for software they sold in their store. The original 
version of this virus has their names and telephone number programmed 
in the code. 


For comparison, the IBM PC was announced in 1980 and went on sale 
October 1981. 


The Pakistani Brain spread rapidly to North American via Europe. 
In less than twelve months it had infected nearly a half-million computers 
in hundreds of universities, corporations and government agencies. 


Cohen conducted five trial runs in which his virus never took more 
than an hour to infect the VAX system. The shortest time to full infection 
was five minutes, the average half an hour. His work was so successful 
that university officials refused to allow further experiments. 


The D:«sartment of the Navy (DON), in its drive toward technological 
sophistication, is becoming increasingly computer dependant. Ships are 
receiving administrative microcomputers and "smart' weapons systems while 
shore establishments have their management information systems 
interconnected by wide and local area networks (WANS and LANS). This 
dependency and interconnection increases the potential of viral infection 
and the threat of data compromise and degradation or loss of system 
performance. Regardless of the source, a campus pranks’=r or a foreign 
power, protecting our systems from viruses will be ess: :tial to ensure 


their reliability. 


B. SOFTWARE CATEGORIES 

Software used by DOD can be broadly categorized as either mission 
critical or mission support. Mission critical software directly impacts on 
DOD’s ability to defend the United States from attack. Such software would 
include missile guidance systems and military forces command and control 
programs. Mission support software, ill other DOD software not dir ctly 
effecting the defense of the United States, would include payroll packages, 
personnel databases, and office automation. 

Development of mission critical software often requires access to 
classified hardware design and performance specifications. Depending upon 
classification, special storage and development facilities, access ~ »cedures, 
and testing criteria may be employed. Additionally, the fielding of hardware 
and software systems would most probably be performed through a secure 


distribution channel. 


Mission support software development will, in general, require access 
to unclassified, or at most, unclassified but sensitive data’. Many .of the 
restrictions for classified projects may not apply. Distribution of hardware 
and software will be through the Central Design Agent (CDA), the standard 
supply system or via open purchase. Unfortunately, this increases the 
vulnerability of our systems since the relative percentage of word 
processors procured by the Navy exceeds the number of missile guidance 
programs. 

Due to the comparatively open nature of development, the relative 
percentages of procurement, and the underlying simplicity of the custody 


chain, I chose to examine viral protection of mission support software. 


C. MICROCOMPUTER RELIABILITY 

The IBM compatible microcomputer’s popularity, widespread availability, 
and general lack of security has made it the target of most viral attacks 
in the last five years. The threat has become so wide-spread that Allstate 
Insurance Company now offers virus insurance. Its home and business 
insurance policies have been extended to cover viral damage _ to 
microcomputers. (Skulason, 1990, #3-35) These are the same systems which 
have been used aggressively for office automation, command LANs, and 
access to sensitive command and control systems such as the Worldwide 


Military Command and Control System (WWMCCS). 


The Computer Security Act of 1987, signed into law 8 January 1988, 
created this category of information. It includes privacy act and contract 
sensitive data. 


With this in mind, I will focus on mission support software for IBM 
compatible hardware only. | Providing viral safeguards for these systems 
is a first step toward overall computer system protection. The question 
then, is "How do we provide protection from viral attack?". 

I will broadly define a virus as any program which replicates and 
spreads itself secretly. Assuming a given computer is not infected when 
manufactured’, the infection must occur during use. This implies the 
infection vector’ is the software’ which is then added to it by the user. 
We can then narrow our research question to "How do we prevent the 
loading of infected software?”. 

Before answering, we must understand the nature of the threat, the 
types of existing viral detection and removal tools, and potential means of 
protecting software. These issues will be addressed in the following 


chapters. 


This is not unrealistic since the vast majority of microcomputers 
dedicated to mission support functions are IBM compatible. Indeed many 
competitively bid procurement contracts have specified this compatibility 
as a requirement. 


A valid assumption since memory is empty and any disk drives are 
empty or unformatied. 


; "An agent capable of transmitting a pathogen from one organism to 
another either mechanically as carrier or biologically by playing a specific 
role in the life cycle of the pathogen.” [Webster's Third New International 
Dictionary] 


Commercial, shareware, or public domain only, since I assume a 
software developer will not write code to deliberately infect and damage his 
own system. 


IT. NATURE OF THE VIRUS THREAT 


A. NAME ORIGIN 

Virus 1s a normal Latin 2nd declension word meaning 'slime’, ‘poison’, 
and ‘offensive’. While its first English usage was in 1599, it was not used 
in its present meaning as ’filterable virus” until 1880. [Oxford English 
Dictionary, Second Edition] The invisible and destructive nature of the 
biological virus led to its adoption as the name for its electronic cousin. 
In fact, many researchers use terms reminiscent of the biological virus: 
vector, infection rate, and vaccine. The plural of ’virus’ as used in 


English, is viruses’. 


B. TYPES OF VIRUSES 
Computer viruses can be categorized in three major classes based 


upon their area of system residence and/or infection: 


- boot infectors 
* system infectors 


executable program infectors 


"An infectious organism, usually submicroscopic, that can multiply 
inside certain living host cells. A non-cellular structure lacking any 
intrinsic metabolism usually comprising a DNA or RNA core inside a protein 
coating." [Oxford English Dictionary, Second Edition] It would pass through 
filters that would stop bacteria. 


Of note is the significant disagreement between academicians 
concerning the ’true’ plural of ’virus’. The first quarter of 1990 saw weeks 
of electronic word war via the VIRUS DISCUSSION LIST and other research 
oriented electronic forums concerning this point. For my part, I use 
’viruses’ throughout this work to represent the plural. 


1. Boot Infectors 
These viruses reside in a disk’s! boot sector. If active in 
memory, a boot virus will infect a new disk by relocating the boot sector 
contents to a previously empty disk sector and marking it as bad in the 
File Allocation Table (FAT). The virus then adds a jump instruction to its 
end and writes a copy of itself to the boot sector.’ The jump ensures that, 
after the boot virus is loaded into memory and executed during booting, 
computer control is passed to the original boot code at it’s new location. 
An infects” disk can infect the system whenever the disk boot 


sector is executed. While memory resident, these viruses can infect any 


DOS disks are organized using a rigid scheme. Each disk in a drive 
is divided into one or more logical volumes. Each logical volume consists 
of four areas: the boot sector containing configuration and bootstrap 
information, an original and backup File Allocation Table (FAT) which holds 
cluster chaining and ownership information, the disk root directory which 
holds information pointing to the first cluster in the FAT chain holding a 
given file’s or subdirectory’s data, and the file area which consists of 
clusters maintaining file data chained by the FAT pointers. 


The boot sector, logical sec’ ~- contains critical infc ation 
regarding the disk medium such as: —-S iame and version, bytes/sector, 
sectors/cluster, number of reserved sectors, number of FATs, number of 
root directory entries, total sectors in the logical volume, media descriptor 
byte, number of sectors/track, number of disk drive heads, number of 
hidden sectors, and the disk bootstrap to load the operating system from 
disk (the ROM bootstrap is smart enough to home the disk drive head, read 
the boot sector from disk, and jump to it in memory). 


1 The "bad" sector marking in the disk FAT ensures that these 
sectors will not normally be examined or altered by the system. 


' Boot infectors typically mark several "good" disk sectors as "bad". 
These sectors are then used to hold the original boot sector code plus 
whatever virus code would not fit in the boot sector. 


A disk’s boot sector is examined whenever drive hardware detects 
a diskette change or upon system reset for logical drive 0O only. 


disk in the system. These viruses are fairly tame since they infect a given 
disk only once and are relatively easy to find. 
2. System Infectors 

These viruses attach themselves to the command interpreter and 
other system files that remain memory resident and reside on bootable hard 
or floppy disks.’ Except for exclusively targeting system files, these 
viruses behave similarly to executable program infectors which are 
discussed below. 

While the relatively small number of systems programs should 
make these viruses somewhat tame, the fact that systems programs remain 
memory resident and are frequently called allow these viruses to cause a 
high degree of infection in a short span of time. 

3. Executable Program Infectors 

These viruses are particularly troublesome since they can spread 
to any executable program: in the system by either appending or 
overwriting. A virus generally appends itself to either the front or back 


end of an executable file Front end appenders situate their code so it is 


The 8086/8088 family of microprocessors are designed so that, when 
reset or powered up, program execution begins at memory address 
OFFFFOH. This lies within ROM memory and contains a Jump instruction to 
the system power up self test (POST) and bootstrap code. The bootstrap 
code loads and executes the system programs MSDOS.SYS and IO.SYS. 
IO.SYS ultimately loads and executes the command interpreter 
COMMAND.COM. 


Any program ending with the suffix COM, EXE, OVL, or BIN is 
considered by the operating system to be executable. 


, According to John McAfee, Chairman of the Computer Virus Industry 
Association (CVIA) and President of McAfee Associates, a Santa Clara, 
California based anti-viral research and marketing firm: 


ex cuted before the host program. After the virus performs 3s task, it 
then returns control to the legitimate code. Back end appenders usuall+ 
add a JUMP instruction in the front end pointing to the viral code. Aft: 
virus execution, another JUMP points back to the original program code. 
Overwriting viruses simply replace a section of the existing code with their 
own instructions. This subgroup is usually detectable earlier in the 
infection process since the host program may no longer function correctly. 
The appenders may slow program performance but will generally escape 
detection ‘intil the virus damage sequence is triggered. 
This type virus usually accomplishes its infection by either: 
* copying itself to another executable file whenever an infected program 
is executed and then passing control to the host program 
by remaining memory residene and infecting each program that is 
loaded into memory 
During infection, the original file size, date, and time may be 
changed. However, sophisticated viruses may save and restore the original 
values when writing the modification to disk. Additionally, to avoid early 


detection and maximize infection, the virus may avoid previously infected 


"Viruses can attach to a program’s beginning, end, middle, or any 
combination of the three. They may fragment and scatter virus 
segments throughout the program or keep the main body of the virus 
unattached to the program, hidden in a bad sector. All known viruses, 
however, [modify the program’s beginning to] ensure the virus is 
executed before the host. If this were not so, the uncertain 
environment in which the virus executed would increase the 
possibility of program failure [and early detection]. Viruses which 
replace entire programs, such as boot infectors, and viruses that 
attack only specific programs [such as system infectors], are the only 
exception to the this rule. These viruses may gain control at any 
point, since the structure of the host program is well known and the 
environment can be predicted." (McAfee, 1989) 


files or delay its damage sequence until infection has reached a 


predetermined level. 


C. PROPAGATION ESTIMATES 


Estimates of viral multiplication rates are not easily obtained for many 


Feasons. 


computer hardware may remain constant but software used and 
preventative measures taken may vary greatly from site to site and 
machine to machine 

many researchers are reluctant to divulge their estimations since they 
are often derived from reports concerning products they are 
supporting 


this information is still considered ’embarrassing’ and ’sensitive’ 


Dr. Fridrik Skulason, virus researcher at the University of Iceland, 
Technical Editor of the Virus Bulletin (UK), and consultant to the Naval 
Computer Incident Response Team (NAVCIRT) at the Naval Electronic 
Systems Security Engineering Center (NAVELEXSECCEN) in Washington, DC, 
has, however, recently released estimates for two of the oldest and most 


wide-spread viruses. | These appear in Figure l. 


Total number of PCs 30.000.000 machines 
Number infected with Jerusalem 100.000-500.000 machines 


Number infected with Brain 100.000-500.000 machines 





Figure l - Estimated PCs Infected with Jerusalem and Brain (Skulason, 1990, #3-64) 


| The Jerusalem and Pakistani Brain viruses are about 51 and 74 
months old, respectively. 


Figure 2 provides the amended estimate if each infection on the same 


machine 1s counted. 


Number of Jerusalem infections 2.000.000-10.000.000 infections 


Number of Brain infections 1.000.000- 5.000.000 infections 





Figure 2 - Estimated Jerusalem and Brain Infections (Skulason, 1990, 4%3-64) 


Of note is the apparent virility of Jerusalem compared with Brain 
even though Brain is a third older. This is primarily due to its targeting 
of executable programs instead of the comparatively rare disk boot 
se_.ors.’ 

Skulason hypothesizes that viral infections increase exponentially over 
time but slow as the virus saturates the system. This can be seen in 
Figure 3. His experience with organizational infections’ indicates that once 
a virus infects a computer, it will usually spread organization wide in one 


to two months. (Skulason, 1990, #3-64). 


| Skulason estimates that 20 infected programs reside on every 
Jerusalem infected machine, and 10 diskettes have been infected by every 
Brain infected computer. 


According to John Mildner, head of the Naval Computer Incident 
Response Team (NAVCIRT) at the Naval Electronic Systems Security 
Engineering Center (NAVELEXSECCEN) in Washington, DC: "Jerusalem 
probably spreads more rapidily since it uses executible files as the 
infection vector. These files are often transfered electronically via bulletin 
boards or computer networks. On the other hand, the virus most common 
to the Navy, the Stoned boot sector virus, is spread by exchange of data 
files on floppy diskette." (Mildner, 1991) 


; Organizations in Iceland are not that large - The Bank of Iceland 
is one of the largest and had about 700 PCs as of mid 1990. 
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Figure 3 - Percentage of Organization Infected vs Time (Skulason, 1990B) 


Skulason shows that the number of infected computers will rise slowly 
when the virus is first introduced, but, assuming favorable conditions, a 
virus will infect 80% of the machines within 2 months. The virus will then 


Once detected, it is usually 


probably remain unnoticed for some time. 
removed swiftly, but, almost never completely.’ When it reappears a month 


or two later, some preventive software is finally installed and the virus is 


defeated. (Skulason, 1990, #3-64) 


D. RELATIVE FREQUENCY 
A virus’s frequency of occurrence is related to its propagation rate 


and age. Viruses which propagate faster such as executable infectors will 


Such as lack of preventive hardware or software, or significant disk 
or program traffic between different computers. 


This is the period in which the virus actively replicates without any 
noticeable performance degradation or damage sequence. 


Particularly if backup files loaded to recover lost data files have 
been corrupted. 


Skulason estimates that, in Iceland, about 5% of all PCs have been 


infected with a virus. However, viewing single organizations, he either 
finds no viruses or an 80% infection rate. 


ik 


be seen more frequently than slower propagators like boot infectors. 
Likewise, older viruses have had longer to establish themselves in the user 
community and will be spotted more frequently than viruses which have 
just been isolated. Figure 4 lists the relative frequency of viruses as 


observed by David Chess, Fridrik Skulason, and Morton Swimmer. 
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Figure 4 - Observation Frequencies (Chess, 1990)(Skulason, 1990, #3-91)(Swimeer, : 1%) 


These figures indicate that at least 70 percent of the infections are 
caused by half a dozen viruses. As of February 1991, 222 major virus 
strains have been isolated. Therefore, more than 70 percent of infections 
are caused by less than 3 percent of the known strains.- This makes the 


virus identification and removal problem much more manageable. 


| Joh’ McAfee identifies 10 viruses (Pakistani Brain, Jerusalem, 
Alameda, Cuscade, Ping Pong, Stoned, Lehigh, Den Zuk, Datacrime, and Fu 
Manchu) which, he believes, represent 95 percent of reported infections. 
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Details of specific infection cases in the United States are provided 
in Appendix A (McDonald, 1990). A chronology of the Dark Avenger virus, 


as told by its author, can be found in Appendix B (Skulason, 1990, #3-97). 


E. VIRAL GENEALOGY 
As the number of viruses increase, so does the difficulty of tracking 
their inter-relations. Figures 5 and 6 provide the genealogy for those 


viruses considered related to others. 
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Ping-Pong ’286 
Typo 





Figure 5 - Boot Infectors (Skulason, 1990, %3-89) 


Like its biological counterpart, a computer virus tends to evolve and 
mutate. This mutation is controlled by programmers who generate new 
viruses from the source or disassembled code of older ones. This process 
often precludes major changes or enhancements and may assist identifying 
new viruses soon after they appear. | Appendix C (McAfee, 1991) details 


4 
infection and damage characteristics for known IBM compatible viruses. 


A recent development, however, has been the use of self encryption 
to hide and avoid detection. 


¢ As of 26 February 1991. 
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Figu:e 6 - Executable Program Infectors (Skulason, 1990, #3-89) 
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III. VIRUS IDENTIFICATION AND REMOVAL 


A. IDENTIFICATION 

Virus identification can either be inadvertent or deliberate. For the 
average PC user, viruses are unknown or something that infects ’others’. 
Either way, little or nothing is done to catch infection before the damage 
sequence is initiated. Infection is inadvertently discovered when the virus 
triggers, performs its destruction, and possibly identifies itself. 

Deliberate identification involves the active use of various software 
tools tailored to locate, identify, and, perhaps, remove viruses. These tools 


fall into three major categories: 


* programs which prevent infection 
* programs which detect infection after it has occurred 


* programs which identify pre-existing infection 


John McAfee, Chairman of the Computer Virus Industry Association 
4 
(cVIA)! and President of McAfee Associates’, a Santa Clara, California 
based anti-viral research and marketing firm, points out that: 


"These products, however, are not always clearly separable in the 
marketplace. Some combine two or more programs, each addressing a 


CVIA is reputed to consist of 95 percent of the anti-viral community. 
Most of the members are vendors of anti-viral products. It is a source of 
anti-viral programs and general virus information. Additionally, it is one 
of the few groups providing cross system (IBM, Macintosh, etc) information. 


McAfee products are discussed in this paper for illustrative 


purposes only. This does not represent endorsement by the author or the 
Department of the Navy. They represent the entire product spectrum. 
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single protection area, into a single package. Others may focus on a 
single type of protection but only provide a partial solution. For 
example, there exist infection detection products that will only detect 
changes to operating system files, ignoring all other executable code.” 
(McAfee, 1989) 


Minimum capabilities and evaluation procedures for these tools have 
been defined by the CVIA and are listed in Appendix D and FE, respectively 
(McAfee, 1989). Appendix F lists some of the commonly used anti-viral 
products and their vendors. 

1. Infection Preventors 

These programs normally monitor the system watching for 
characteristic viral activities’. If detected, they suspend activity, alert the 
user, and offer to terminate the suspect program. 

The primary benefit is that all suspicious activity will be caught 
and viruses will not infect tne system or spread.’ This means that strain 
identification and removal is not required. Conversely, the drawbacks 
include numerous interruptions to valid programs’ using these system 


4 


3uch as absolute sector disk I/O, disk I/O to systems files, and 
altera on of interrupt vectors. 
; 
* With the exception of boot infectors. No software technique can 
prevent initial infection from a boot virus. 


' McAfee believes these programs require a user with a "fair amount 
of technical competence" to discriminate between legitimate program activity 
and a ?al virus threat. 


"Some applications modify their executable modules during the 
configuration phase. Compilers, assemblers and linkage editors 
legitimately modify or replace executable code. The DOS SYS command 
will legitimately modify the boot sector and operating system files. 
These and other programs may cause anti-viral products to flag the 
activity and notify the user. The user must have sufficient knowledge 
of the program or activity in process to determine whether to allow 
it to proceed or to terminate it. Many system users do not have the 
necessary technical depth to make a valid decision" (McAfee, 1989) 
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calls, user de-sensitization due to false positives , and reliance on the 
virus being ’well behaved”. 

These products should be tested, prior to use, to determine the 
degree of protection afforded executable files and the product’s sensitivity 
to valid activities which might appear suspicious. 

zZ. Infection Detectors 

Detection products operate by vaccination or status logging. 
Vaccinators modify executable code to include a self test module which 
generates a run-time warning whenever the code has been modified. Status 
loggers create a baseline file containing key file information (sizes, dates, 
checksums, etc.) and routinely recheck this information to see if it has 
changed. If a modification is discovered, a warning message is given to 
indicate the areas of infection. In both methods the key assumption is that 


the system is not infected prior to installation. 


If the product flags too many legitimate activities, the user becomes 
conditioned to respond with ’continue’ without reading the warning. 


The assumption that viruses perform I/O through system calls or 
software interrupts is reasonable because it allows execution on a wide 
variety of hardware. John McAfee, however, notes that some virus 
designers are: 


"taking the extra effort, and running the increased risks, of 
interfacing directly to the hardware input/output devices. By doing 
so, they completely neutralize the infection prevention products’ 
interrupt monitoring. No matter how cleverly software interrupts are 
trapped, or memory monitored, it is ineffectual if the virus never 
gives up processor control through an operating system call.’ 
(McAfee, 1989) 
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Advantages include checking at boot time instead of program 
execution and avoidance of interrupt monitoring’. Drawbacks include on 
line baseline file maintenance making it vulnerable to tampering, the 
necessity of strain identification and disinfection, and the assumption that 
the system is infection free when the baseline is generated. A serious 
drawback of vaccination products is that they can not detect viruses that 
replace code rather than modify it since any vaccination code would never 
have an opportunity to execute.’ 

Since these products identif infec-ion after it has occurred, 
testing should be conducted, prior to use, to determine if they can detect 
modifications to executable programs such as the boot sector, the operating 
system, or an application program. John McAfee explains that: 

"Many detection products use the virus attachment profile to 
speed system checking. If every byte of every program is 
processed in some comparison technique global checking may take 
some time. Systems containing many hundreds of large programs, 
may require anywhere from 5 to 15 minutes to complete the 
audit. Since a global scan should be performed at least daily, 
this time requirement is a significant nuisance to the average 
user and a deterrent for the implementation of the product. 
Products that only look for the characteristic initial instruction 
modifications, on the other hand, would complete the same audit 
in a matter of seconds."(McAfee, 1989) 

3. Infection Identifiers 


Identification products scan a system using signature byte strings 


to uniquely identify disk or file infection and may often provide 


Regardless of a virus’s sophistication, some executable code will have 
changed after infection. 


Boot sector viruses, for example, replace the boot sector with 
themselves. 
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disinfection and recovery assistance. Their primary function, however, is 
identification. 
The main benefits are the lack of assumptions and the relative 
speed of execution. The main drawback is the almost constant stream of 
4 
new product releases” required as new viruses are isolated and old ones 
mutate’. 
John McAfee describes the development of identification products: 
"The virus must first be discovered and isolated. Then it must be 
disassembled and analyzed. Finally an effective countermeasure must 
be designed, implemented, and distributed to the public. The time lag 
for this process is a few months to a year or more. This window of 
opportunity for new virus developers will be a continuing barrier for 


such products." (McAfee, 1989) 


These products can best be evaluated by their success at 


removing an actual infection. 


B. REMOVAL 

Fortunately for the microcomputer user community, if viral infection 
can be identified prior to the initiation of the damage sequence, a virus 
can usually be removed without loss of data or program files. Two general 


categories of disinfection products exist: 


* products which remove a specific virus or group of viruses 


* products which remove all] viruses 


They can determine if a system is clean prior to installing a 
prevention or detection product. 


McAfee releases a new version of VIRUSCAN about every 3 months. 
Viral researchers must then identify a signature byte string which 


uniquely identifies it. That signature string must be included in the next 
release of the anti-viral product. 
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1. Virus Specific Disinfectors 
These products are able to target a specific virus strain or group 
of strains for removal. They are often included with, or as part of, a 
detection or identification product.’ Authors of these programs frequently 
release revisions as new or mutated viruses are isolated.’ 
As elsewhere, terminology is a point of contention within the anti- 
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virus industry. With luck, the following terms will become industry 


standards: 
signature string: a juence of bytes used by anti-viral programs to 
check if a program infected 


- identification string: a sequence of bytes used by a_irus to check 
if a program is infected 
2. Universal Disinfectors 
A universal virus detector and disinfector (UVD) would detect and 
remove viral infections both known and unknown. This, of course, depends 
on our ability to define viral activity under all circumstances. 
We can appreciate the proble . by refining our virus definition. 


Fred Cohen defined a virus as "a program that can infect other programs 


As of February 1991. 217 major virus strains exist. If modifications 
to these viruses are cour -d, there are 475 known IBM PC viruses. 


McAfee’s VIRUSCAN can remove many of the most common viruses. 
The disinfection product CLEANUP is also provided to remove all viruses 
which VIRUSCAN is capable if identifying. 


John McAfee releases a new version of CLEANUP about every 3 
months. 


| The terms have been defined as used by IBM, wut, they have been 
used interchangeably by other researchers. 


20 


by modifying them to include a slightly altered copy of itself" (Cohen, 


1984). Unfortunately, this remains valid only if modernized as follows: 


- "program" should also include boot sectors, INITs and all other forms 


of executable code 


- "include’ must also cover viruses that overwrite the victim and mav 


destroy it completely 


"slightly altered" is inaccurate. One can imagine a virus 


that 


includes only a part of itself in infected programs (Skulason, 1990, 


#3-24) 


Consider Figure 7. 


Program Pl 
Display "This is a copy utility” 
it 


Display "Name of input file ? 
Input [n-FPFile 


oO" 


Display "Name of output file ? 
Input Out-File 

Copy In-File to Out-File 
End 





Figure 7 - Copy Utility Pseudo-Code (Skulason, 1990, %#3-24) 


I Skulason details a program with three parts: 


- Part A contains the main program 


* Part B contains program locating and memory residency procedures 


- Part C contains I/O routines. 


Assume Pl contains A+B and P2 contains A+C. Singularly, since they 
unable to replicate, they are not viruses. When executed, Pl and P2 
not infect other programs. P1 will hide B in memory and execute 
original program. P2 can check if B is present in memory. If so, A, B 


are 
will 
the 
and 


C are combined in memory and executed. This new program uses B to find 


More programs to infect, using C, with A+B or A+C. The program A, B 


and 


C is a virus. However, it includes inert code instead of a slightly altered 
copy of itself in other programs. The virus only activates when its parts 


are combined. (Skulason, 1990, #3-24) 
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If we tell Pl the input fil: is itself and some existing progrim is 


the output file, Pl will behave, and be classified, as an overwriting virus.’ 


P1, however, iS not a virus since: 


* It asks for the name of source and target files; and, 


* It destroys the victim instead of executing it after the virus. 


Objection 2 may not be valid, however, since this is how some existing 
viruses work. (Skulason, 1990, #3-24) 


Consider Figure 8. 


Program P2 

Display "Name of output file ?" 
Input Out-Pile 

Copy P2 to Out-File 
End 


Program P3 
Display "Name of input file ?" 


Input I[n-File 

Select Out-PFile at random 
Copy In-File to Out-Pile 
End 


Program P4 
Select Out-File at random 
Copy °4 to Out-File 

8nd 





Figure 8 - Potential Virus Pseudo-Code (Skulason, 1990, #3-24) 


We want a UVD to identify P4 as a virus. It should also indicate 


that P2 and P3 might be virus like in some circumstances. Unfortunately, 


l As well as most operating systems since they ’infect’ other programs 
in the same way. A compiler used to compile a copy of itself would also 
qualify. 


Ze 


determining those circumstances is where the difficulty arises. (Skulason, 


1990, #3-24) 


Assuming that the examined program and it’s environment are of 
finite size, I/O operations transfer finite amounts of data, and the UVD 
program runs on a different machine, a UVD may be possible but only on 
a machine many orders of magnitude more powerful than that running the 
examined program. If the first is a Sinclair ZX80, with 1K of memory, the 
second would need to be more powerful than all current super computers 
combined. (Skulason, 1990, #3-24) 
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IV. VIRUS INFECTION PREVENTION MET'YODS 


Prevention can be divided into three areas: 


user training 
hardware measures 


software measures 


As USER TRAINING 
The basic building block of security is user training. Hardware and 
software can not protect a user from himself. A solid foundation in anti- 


viral measures can be laid by a two step training program: 


basic precautions 


virus recognition 


1. Basic Precautions 


Most viral damage can be easily prevented by simple user 


precautions: 


- boot only from write protected copies of the distribution diskette 
- if the system has a hard disk, never boot from a floppy disk 


- get file attributes to read only on as many executable files as possible 
to help prevent spread of infection 
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consider public domain, shareware, and borrowed software infected 
until proven clean 


watch for changes in system activity such as increased disk accesses, 
unusual error messages, lost disk space, disk access at odd time, 
decreased available memory, slow response, Or Unusual screen displays 
or sounds 


in a network environment, load proven software to a file server and 
set file attributes to read only 


do not use master/distribution diskettes as working diskettes 


keep master/distribution diskettes in a safe place, away from the 
computer working area 


-* make frequent backups of changing data files 


2. Virus Recognition 
A Virus Simulation Suite is available to mimic the visual and 
audible effects of the most common microcomputer viruses.’ Like their 
infectious counterpart, these programs are terminate and stay resident 
routines. Unlike the real virus, however, they can be turned on and off 
by the user and are not infectious. Some have a programmable delay, 
usually in minutes, to simulate the replication period. Simulations currently 


available include: 


Actually, the same holds for shrinkwrapped commercial software. 
Shrinkwrap does not mean virus free. It is most frequently used in 
conjunction with the licensing language, i.e., breaking the shrinkwrap 
means agreement with the terms of the license. Package encapsulation to 
reduce the risk of loss or contamination and increase the probability that 
tampering will leave evidence is an incidental benefit. 


The Virus Simulation Suite is written and maintained by Joe Hirst 


at the British Computer Virus Research Center, 12 Guildford St, Brighton, 
East Sussex, BN1 3LS, England. He can be contacted at 0273-26105. 


Zo 


- Cascade 

> Den Zuk 
Fu Manchu 
Ping Pong 


Jerusalem 


These simulations could help develop viral activity recognition in 


users. 


B. HARDWARE MEASURES 

Virus protection, as in many areas of computer security, may be 
possible, but, certainly not foolproof, without hardware assistance. Many 
incidence of viral infection ; could be reduced or eliminated by the 


introduction of a few hardware elements of varying cost: 


write protect tabs 
- tamper-proof shrinkwrap 


- CD ROM 


1. Write Protect Tabs 
These devices are inexpensive and easy to use. Most computer 
systems, and certainly those manufactured in the last five years, implement 
disk write protection in hardware vice software. Since this hardware 
inhibits disk writing if the tab is in place, viruses can not corrupt a write 
protected disk. Write protect tabs should be on all floppies put in a 


system. 


The hard drive or a dedicated flopp -:ould then be used for output. 
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Original distribution diskettes should be write protected as soon as 
removed from the shrinkwrap and either installed on the hard drive or 
diskcopied to other floppies to make a working copy of the software. 

2. Tamper-proof Shrinkwrap 

Unfortunately for the buyer, many software stores have the 
capability to re-shrinkwrap software which has been purchased and 
returned or used for showroom demonstration. While this makes the product 
once again available for sale, it does nothing to protect the buyer from 
diskettes which were infected by the machine on which they had been 
previously used. To preclude this unsuspected hazard, tamper-proof 
shrinkwrap, perhaps bearing the vendor’s corporate logo, could be used. 
Opening and resealing of software could be immediately determined by 
inspection. 

3. CD ROM 

Since systems are infected by using infected software, the most 
certain means of preventing infection is using only software which is 
certified virus free. We must then ensure it is never unintentionally 
modified. One method is the exclusive use of software on CD-ROM. This 
optically read storage medium, while much slower and more error prone 
than electrically read magnetic media, is forever inscribed with the digital 
data representing program and data files. All program output would be 
directed to regular magnetic media. The drawback is the prohibition of 


user software customization. 


VA 


C. SOFTWARE MEASURES 


The last software method for combatting viruses includes two types 


of measures: 


virus scanners which search for viruses in memory and on disk 


software which authenticates user software prior to use from a known 
true baseline 


1. Virus Scanners 
Virus scanners are programs which search computer memory and 
disk storage looking for signature byte strings characteristic of known 


viruses. As previously discussed, there are three major categories: 


* programs which prevent infection 
* programs which detect infection after it occurs 


* programs which detect pre-existing infection 


2. Authentication Methods 
Software, both commercial or government produced, is shipped 
from vendors to either retailers or users. While undergoing development, 
we assume that it is protected. However, while sitting in storage, or cn the 
user system itself, we consider it vulnerable. (Spafford, 1990) 


Given this, we may develop a software authentication process 


consisting of the following: 


- the vendor generates digitally signed software 
the user verifies the signed software 
the user installs and customizes the software on his system 


* the user digitally signs his installed copy 
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the user’s system checks the executing software using hardware 
and/or software authentication methods (Davida, 1989, p 313) 

Hardware is generally more tamper resistant than software. The 
same holds true for hardware based authenticators. The _ actual 
authentication method used, however, will be decided based on the level of 
security (degree of trust) required and the dollars available for procuring 
this means. 

The inherent vulnerability of software based security systems is 
often compensated for by requiring complex access procedures, 
sophisticated self verification, or booting from special software diskettes. 
Unfortunately, this may be more than the average user will religiously 
adhere to. Conversely, complex hardware based authentication systems 
could be subverted by implanting malicious code into the IC chips during 
the design process. This necessitates testing and _ validation of 
authentication equipment by external means. Validation testing could be 


eased by simple authentication hardware design since: 


- chip complexity would be low 


- chips could be procured from multiple sources making tampering 
impractical 


* multiple chip design would require the malicious code to be spread 
across devices to perform its task 


- chips older than computer viruses could be used (Davida, 1989, p 315) 


| Acknowledging this, the Department of Defense has recently started 
work on its own semiconductor plant. This plant would produce "clean" IC 
chips for use in sensitive equipment. 
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The key problem then is the verification of the verifying means. 
A possible solution is the use of cryptography and digital signatures to 
‘sign’ a software package. The vendor signs his release or update and the 
user authenticates the signature. Once validated, the software can be 
installed, customized as required, and ’sealed’ by the user using his own 
digital signature. 

A program may be checked when installed and each time it is 
saad: The question of authentication granularity, like the hardware 
or software authentication issue, is ~ne of degree. Determir ‘ion of the 
level at which to sign an executable, i.e., program, process, or instruction, 
is a function of the degree of trust required, the speed of the 
authentication process, the size of the executable, and the method used. 


(Davida, 1989, p 317) 


A complete check may not be possible if segments are only loaded 
as needed. In timesharing environments a process is at risk whenever it 
doesn’t control the processor. Events such as paging, segmentation, or 
process swapping open the code to tampering. Re-authentication would then 
be required prior to regaining control. 
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V. AUTHENTICATION METHODS 
This section examines the theory behind’ several _ software 
authentication methods’ broadly categorized as ‘digital signature’ 
generators. A digital signature is a property, private to a user or process, 
that is used for signing messages. A reliable digital signature must satisfy 
five requirements: 
- the signature must be unique and be able to be generated only by 
the user 


- it must be computationally infeasible for authentic signatures to be 
generated (forged) by unauthorized users 


* any receiver of a digitally signed message (and any dispute 
arbitrator) must be able to authenticate the signatures authenticity 


even after a considerable period of time 


digital signatories must not be able to deny an authorized signature 
as a forgery 


- digital signatures must be cheap and easy to generate (Seberry, 1989, 
Dp» 155) 
The digital signature, since it’s non-forgeable, establishes sender 
authenticity equivalent to a written signature. 
This work advocates implementation of initial authentication means with 
the least delay and cost possible. Therefore, the following methods, ordered 
from the simple to the complex, were reviewed since they represented 


existing, well understood, and easily implemented technology. They are: 


checksums 
* cyclic redundancy codes 


* encryption 
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* message authentication codes 


- hybrid systems 


A. CHECKSUMS 

The simplest and fastest form of digital signature is the checksum. 
Checksums treat a file as a series of binary numbers. By summing all the 
binary numbers, a checksum or total value can be found. Changes to files 
can be readily determined by recalculating the checksum and cc _ 2ring it 
with the previous result.! 

A file changed by a virus will have an altered checksum unless the 
virus tries to compensate. Unfortunately, it is quite easy to determine a 
file’s stored checksum and determine an additive byte string which 
’corrects’ the corrupted file’s checksum. Therefore, checksums do not meet 


requirement 2 for reliable digital signatures and are not sufficiently robust 


to detect changes in the face of a clever attack. 


B. CYCLIC REDUNDANCY CODES 

Most commonly used for error detecting during data transmission, 
polynomial or cyclic redundancy codes (CRC) can be used to detect changes 
caused by viruses. CRC codes are generated using input bit strings as a 
representation of a polynomial with coefficients of 0 or 1. A n-bit message 
or message segment is regarded as the coefficient list for a polynomial of 


degree n-1l with n terms, ranging from xi! to x, 


! This method is used by many operating systems including DOS to 
determine if reads and writes from and to disk have been performed 
correctly. 
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Polynomial arithmetic is performed modulo 2 and is functionally 
equivalent to an exclusive or operation. Long division, using modulo 2 
subtraction, can only be performed if the dividend has as many bits as the 
divisor. 

The CRC is computed by first selecting a generator polynomial of 


degree r, G(x), with at least the high and low order bits set to 1.! 


Next, 
r zero bits are appended to the low order end of the n-bit message or 
message segment so it now contains ntr bits and corresponds to the 
polynomial x’ M(x). The generator bitstring (the coefficients of G(x)) is then 
divided into this new bitstring (the coefficients of x M(x)) using modulo 2 
division. The remainder is then subtracted from the x M(x) bitstring using 
modulo 2 subtraction. This resulting bitstring, polynomial T(x), is the new 
message or message segment which is then sent. Upon receipt, it is divided 
by G(x). If a remainder exists, a transmission error, or virus corruption, 
has occurred. 

Since this technique is more sophisticated than a checksum, it can 
detect more subtle changes. Checksums rely solely on addition which is 
insensitive to the order of the added numbers and can not detect byte 
swapping. CRCs, however, can detect bit and byte swapping due to the 
position dependent logic used.’ While most alterations will be caught, the 
CRC method will not detect errors or corruptions corresponding to 


polynomials containing G(x) as a factor. If G(x) contains two or more terms 


Three polynomials have become international standards for G(x): 
CrCelZ, <n =10,,and CRC-CCITT. 


CRCs are frequently used in floppy disk controllers in order to 
determine whether information has been correctly retrieved from disk. 
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(order r >1), all single bit errors will be discovered. By making x+l a 
prime factor of G(x), we can catch all errors consisting of an odd number 
of inverted bits. Lastly, a CRC code with r check bits will detect all burst 


| Probability of being 


errors of length <=r. Larger bursts have a ie 
unnoticed. (Tannenbaum, 1989, pp 210-211) 


The bottom line is that requirement 2 for reliable digital signatures 


1s not met. 


Cz ENCRYPTION 

Cryptograph se ciphers to tra. >form standard piaintext messages 
into secret ciphertext ones. This process, called encryption, and its 
reverse, decryption, are controlled by one or more cryptographic devices 
called keys. 

Ciphers are typically classified in one of two general types: 
transpositions or substitutions. The former rearrange data bits or message 
characters while the latter replace bits, characters, or character blocks 
with previously chosen substitutes. Most computer applications, such as the 
National Instit’ -e of Standards avd Tec: .ogy (NIST) Digital Encryption 
Standard (DES) use both techniques. 

Cryptoanalysis is the science of cipher breaking. A cipher is 
breakable if it is possible to determine either the plaintext or the key from 


the ciphertext, or the key from plaintext-ciphertext pairs. There are three 


basic methods used for attacking ciphers: 


Often implemented in a combination of hardwa~*- and software. 
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* ciphertext only 
known plaintext 


chosen plaintext (Denning, 1982, pp 2-3) 


A ciphertext only attack requires the determination of the key solely 
from intercepted ciphertext, knowledge of the method of encryption, 
purloined plaintext, knowledge of the ciphertext subject matter, and testing 
for high frequency use words. The known plaintext attack method uses 
knowledge of some plaintext-ciphertext pairs. Ciphers should be accepted 
for use only if they can withstand a known plaintext attack using an 
arbitrary number of plaintext-ciphertext pairs. The last method, chosen 
plaintext attack, is the most favorable for the cryptoanalyst. This attack 
assumes possession of the ciphertext corresponding to selected plaintext.’ 
A cipher is unconditionally secure if, no matter how much ciphertext is 
intercepted, there is not enough information to determine the plaintext. 
(Denning, 1982, pp 2-3) 

While all ciphers are breakable given unlimited resources and time, we 
need not develop them to withstand open-ended attack. A cipher which is 
computationally infeasible to break will suffice. Computationally secure 
ciphers can not be broken by systematic analysis with reasonable 
resources and time. 

| Encrypted computer source programs is an example. The ciphertext 
must contain certain keywords such as begin, end, loop, if, while, read, 
write, etc. An educated guess as to their placement can be made and the 
attack begun. The same can be done with the executable version of the 
software if the equivalent machine instruction byte codes are Known. 

Databases have been identified as being particularly susceptible to 


this type of attack if users can insert records into the database and then 
observe the changes in the stored ciphertext. 
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1. Cryptographic Systems 


A cryptographic system has five components: 


a plaintext message space, M 

a ciphertext message space, C 

a key space, K 

a family of encrypting transformations, Be: M=>C 


a family of decrypting transformations, D,: C=>M (Denning, 1982, pa 


A given encrypting or cecrypting tr :sformation is defined by an 
algorithm common to the entire family but using an unique key. For a 
given key K, the decrypting transformation Dy is the inverse of the 
encrypting transformation Ey. such that D, (Ey (M))=M. The transformations 
Ey and D, are described by parameters called the encryption key and 
decryption key, respectively. (Denning, 1982, p 8) 

Cryptosystems must satisfy three general conditions: 

* the encrypting and decrypting transformations must be efficient for 
all keys 
the system must be easy to use 


the security of the system should depend only on the secrecy of the 
keys and not on the secrecy of the algorithms E or D (Denning, 1982, 


p 8) 

The first requirement is essential for a computer based application 
since data encryption and decryption, usually performed at transmission 
time, must not be a bottleneck. The second requirement implies it must be 
easy for the cryptographer to find a key with an invertible transformation. 


The last requirement implies that it should not be possible to break a 
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cipher simply by knowing the method of encryption or the algorithm used. 
(Denning, 1982, p 8) 
2. Reasons for Cryptography 


There are two basic reasons for using cryptographic systems: 


secrecy 


authentication 


a secrecy 
Secrecy requires that plaintext data be impossible to 
determine from intercepted ciphertext: 

- it should be computationally infeasible to determine the decrypting 
transformation D, from intercepted ciphertext C, even if the 
corresponding plaintext M is known 
it should be computationally infeasible to determine plaintext M from 
intercepted ciphertext C (Denning, 1982, p 9) 

Secrecy, therefore, requires only that the transformation D, 
(the decryption key) be protected. (Denning, 1982, p 9) 
b. Authenticity 
Authenticity requires that a false ciphertext C’ can not be 
substituted for a ciphertext C without detection: 

- it should be computationally infeasible to determine the encrypting 

transformation Ey given C, even if the corresponding plaintext message 


M is Known 


* it should be computationally infeasible to find C’ such that D(C’) is 
valid plaintext in the set M (Denning, 1982, p 9) 
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Authenticity, therefore, requires only that the transfc -mation 
Ey (the encryption key) be protected. (Denning, 1982, p 9) 
3. Types of Cryptosystems 


Cryptosystems can be placed into two broad classes: 


symmetric 


asymmetric 


a Symmetric Cryptos;ystems 
These systems are also called one-key cems since the 
encrypting and decrypting keys are the same or easily derived from each 
other. If both Ey and Dy are protected, both secrecy and authenticity are 
ensured. Secrecy can not be. separated from authenticity since making 
either Ey or D, public exposes the other. Therefore, all the requirements 
for secrecy and authenticity must hold in one-key systems. (Denning, 1982, 
p 10) 
b. Asymmetric Cryptosystems 
T ese systems are also called two-key systems with Ey and 
D, such that it is computationally infeasible to determine one key from 
knowledge of the other. In another sense, Ey and Dy may be thought of as 
one-way functions since they are easy to compute but computationally 
infeasible to invert.! This allows publication of one without endangering 


the other. E is protected for authenticity, while protecting D, would 


This means its very difficult to determine a pla’ntext message from 
the ciphertext. 
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ensure secrecy. This duality makes these cryptosystems ideally suited for 


creating digital signatures. (Denning, 1982, p 11) 


D. MESSAGE AUTHENTICATION CODES 

Although these functions use cryptographic means to create a message 
authentication code (MAC), I will discuss them separately from 
cryptosystems. These ciphers are primarily used in applications where the 
need is not the decryption of transmitted data but the determination of a 
correspondence between a message M  and_e ciphertext C. This 
correspondence is tested by encrypting M and comparing the result with 


c,! Several types of MAC systems exist. I will examine the following: 


- public keys cryptosystems 


* message digests 


1. Public Key Cryptosystems 
The public key system, an asymmetric cryptosystem, allows two 
users to hold both a public and private key and communicate with each 
other knowing only the others public key. 
User A has a public encrypting transformation (key) E, which may 
be widely known, and a private decrypting transformation (Key) D, which 
is known only to him. While the public key is derived from the private key 


by a one-way transformation, it is computationally infeasible to find D, (or 


Computer logon passwords may be encrypted in this method. Since 
they can not be decrypted, they are secure. Yet, when a user enters his 
password at logon time, the transformation is applied and the encrypted 
logon password is compared with the stored encrypted true password. If 
they match, logon is achieved. 
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its equivalent) from it. It is possible to apply these transformations or 


keys to ensure three different outcomes: 


secrecy 
authenticity 


secrecy with authenticity (Denning, 1982, pp 11-12) 


a Providing Secrecy 
If A wishes to send B a message, and knows B’s public key 
Ey 5 he can transmit M to B in secrecy by sending the ciphertext C = Ey (M). 
On receipt, B decrypts C using his private key D, getting the plaintext 
message M = D(C) ~ D, (E,(M)). While this process provides secrecy, it does 
not provide authentication since any user with access to B’s public key 


could send a message to A or replace one with his own. (Denning, 1982, p 


12) 
b. Providing Authentication 
For authentication, M must be transformed using A’s private 
key Gre D,(M). On receipt, B uses A’s public key M = E,(C) = E,(D,(M). 


Authenticity is provided since only A can apply the private key. 
Unfortunately, secrecy is not provided since anyone with access to the 
public key can obtain the plaintext. (Denning, 1982, p 12) 

c. Secrecy with Authentication 

To achieve both secrecy and authentication, A and B must apply 
both sets of transformations. A first applies his private key on M to assure 
authenticity C’ = D,(M). He then encrypts this with B’s public key to 


provide secrecy C = E,(C’) = E,(D,(M)). (Denning, 1982, p 13) 
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2. Message Digests 

The public key system can generate a digital signature by tising 
the sender’s private key. This results in a signed message which is, 
however, twice the size of the original. To alleviate this, most techniques 
make use of data compression before forming the signature. Here, we take 
aN bit message and break it up into units of n bits (where n << N). The 
transformation is then applied to each of these units with the results 
combined to form a signature of n bits called a message digest. The kev 
is ensuring that computing identical digests for two different messages is 
computationally infeasible. (Seberry, 1989, p 156) 


Two message digest generator methodologies follow: 


hash functions 


the RSA Signature Scheme 


a Hash Functions 
These are one-way functions which take variable size input 
strings and return a fixed size unique output string. The primary use of 
hash functions is to determine if there have been any changes made to a 
file. 
Application of one-way function F on a plaintext message M 


yields a fixed size hash code H = F(M). If M is an executable program file, 


Hy F(M) is its hash code. If M is altered in any way, a new hash code, 


H, 


F(M’), will result. Thus, tampering can be detected by comparing the 


new hash with the previously computed, and presumably correct, one. 
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The property of one-way hash functions allowing their use 
for authentication is the computational infeasibility of finding a secon. 
message M’ that will generate the same hash code H as the original message 
M. Because of this, a relatively small H, 128 to 256 bits in length, can be 
used to authenticate very large files. (Merkle, 1989A) 


Formally, secure one-way hash functions have four properties: 


F can be applied to an M of any size 
F produces a fixed size H 
* given F and M, it is easy to compute H = } 
given F, it is computationally infeasible to find a different input M’, 
such that M <> M’ and F(M) = F(M’) (Merkle, 1989B) 

Since practical aSaneneon requires a known input size, the 
hash code is normally developed in two steps. First, function Fa is defined. 
It is similar to F but accepts only fixed size inputs. Fy is used repeatedly 
to construct F via bitwise concatenation. All properties of F hold for Fy 
with the exception of the fixed input size. De :cing M given H is now 
equivalent to deter ining the key given the p. text and the ciphertext. 
(Merkle, 1989B) 

b. The RSA Signature Scheme 

The RSA scheme! uses both the public key cryptosystem and 
data compression to form a digital signature. Assuming A wishes to send 
Ba signed message M, he first shortens it using compression to arrive at 
the message digest M) = F(M). Next, A encrypts the digest using his 
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Named as a supported algorithm in the NIST/© I Implementor’s 
Workshop Agreements of Dec 1989. 
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private key to obtain the signature M, = D, (My ) = D(F(M)). The message and 
signature pair (M and M,) are then forwarded to B. 

On receipt of M and Mos B reproduces the message digest by two 
different methods. First, the digest is recreated from the signature bv 
applying A’s public key M) = FE, (My). Then B produces his own copy of the 
digest using the compression function (since it's public). If the digest 
obtained from A’s signature equals the digest B created, the signed M is 


accepted as authentic. 


E. HYBRID SYSTEMS 

These systems generally use a combination of methodologies to optimize 
the speed of computer processing versus level of trust. For example, a DES 
based system makes major demands on a personal computer due to the 
complex mathematics required for encryption.! In order to speed the 
processing from the user’s viewpoint, a hybrid mixture of DES and CRC, 
or other means, may be used. This usually results in a small percentage 
of a file being examined with a sophisticated MAC, and the remainder 
examined with a high speed CRC algorithm.’ Sophisticated cryptographic 
techniques are used to assure that attackers can not predict which bytes 
are examined by each method. Additionally, results of all cryptographic 


calculations are carried forward into all subsequent calculations. This 


In fact, actual bit manipulation is most often implemented in 
hardware for both speed and security concerns. 


Perhaps the portion examined by the MAC would be the code 
sections most frequently modified by viruses. 
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results in a digital signature that is faster than a DES MAC and stromeen 


than a CRC. (Bosen, 1989, pp 7-9) 
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VI. PRACTICAL SOFTWARE AUTHENTICATION 


This section examines several commercially available products which 


make practical use of the theory previously discussed. 


RSA’s MD4 algorithm 
RSA’s CHECK and SIGN programs 


Enigma Logic’s VIRUS-SAFE 


A. MD4 

This package, programmed and maintained by Ronald Rivest of RSA 
Data Security, has been placed in the public domain for review and 
possible adoption as a standard. MD4 inputs a message of arbitrary length 
and produces a 128 or 256 bit message digest. 

It is considered computationally infeasible to produce two messages 
having the same message digest, or any message having a specified target 
message digest. Although MD4 is relatively new, the security provided 
should be sufficient for implementing very high security hybrid digital 
signature schemes based on MD4 and a public-key cryptosystem. (Rivest, 


1990) 


As have been the two previous MD family algorithms MD2 and MD3. 
These were circulated throughout the industry as INTERNET RFC 1113 and 
1114. MD4 has been distributed as RFC 1115. 


RSA conjectures the difficulty of deriving two messages having the 


same message digest is on the order of 2° operations, and, that of anv 
message having a given message digest is on the order of 2” operations. 
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The C version of the MD4 algorithm, listed in Appendix G, is coded for 
a 32-bit word/8-bit byte machine and runs at 1450, 70, and 32 kBytes per 
second on a SUN Sparc Station, DEC MicroVax II, and 20MHz 80286, 


respectively. (Rivest, 1990) 


B: SIGN AND CHECK 

RSA Sign & Check are two programs which allow users to sign files 
with non-forgeable digital signatures and to cher’ a1 given signature’s 
validity. These signatures are based on the highly t ted RSA public key 
cryptosystem whic}. nas withstood intensive mission critical commercial use 
as well as fourteen years of vigorous challenge from the academic and 


scientific communities. 


C. VIRUS-SAFE 


This product relies on three different methods for producing MACs: 


cyclic redundancy codes 
- American National Standards Institute (ANSI) standard x9.9! 


International Standards Organizat’ ». (ISO) standard 8731-< 


VIRUS SAFE allows several methods of operation to optimize security 


versus performance.’ The frequency and thoroughness of file examination 


ANSI X9.9 describes a way of using DES to calculate a MAC which 
is believed impossible to forge. 


ISO 8731-2 is currently used in the international banking community 
to authenticate funds transfer. 


The thoroughness of file examination which makes unauthorized 
modification impossible to remain undetected takes time and decreases 
DEOGUEELIVIE-. 
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can be optionally set either during software installation or execution such 


as: 


* whether or not a file should be examined at all 
when to examine the file (at boot or execution time) 
how frequently to examine the file (every time, every other, etc) 


how thoroughly to examine the file (the ratio of MAC to CRC) 


For example, someone using a word processor could opt for thorough 
examination every 15th execution instead of each time it’s used. A 
programmer who infrequently uses a debugger may want to have it 
examined every time it is used. The infrequent use means the productivity 
impact is small, even if a thorough examination is performed. Other non 
sensitive program and data files can be examined in a more routine manner, 
such as, using a high speed algorithm when the computer is booted. This 
approach could be up to ten times as fast, but, not offer the level of 
security of a MAC. (Bosen, 1989) 

On a 10 MHz AT, 100 kBytes can be authenticated in 3.2 seconds using 


a hybrid DES and CRC algorithm. (Bosen, 1989) 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


Earlier, I asked, "How do we provide protection from viral attack?". 


I concluded the appropriate question should be, "How do we prevent the 


loading of infected software?". In retrospect, the first question allows us 


to define the foundation for the paradigm to answer the second. 


fold 


Serious protection from viral attack should be implemented as a three- 


program: 


user training 
~ 


virus detection and removal 


software authentication 
The program, however, is best executed in two phases: 
confidence building 


assurance building 


CONFIDENCE BUILDING 


These measures instill confidence in the user and organization that 


computer viruses are not omnipotent programs written by omniscient 


programmers. Instead, they are damaging, but common, nuisances which can 


be recognized and defeated with a little effort and understanding. 


Confidence building measures would entail the first two-thirds of the three 


step program: 
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user training 


virus detection and removal 


1. User Training 
A solid foundation for further anti-viral efforts must be laid by 


training computer users in two areas: 


* basic precautions 


viral recognition 


The basic precautions will provide good user practices to reduce 
the impact of viral damage, slow infection spread, and, hopefully, eliminate 
new infections. A user’s ability to recognize viral symptoms, either by 
suspicious activity or visual or audible cues is important. Recognition, 
before the initiation of the damage sequence, will be damage and infection 
limiting. Use of virus simulations will provide safe and realistic recognition 
patterns. 

2. Virus Detection and Removal 

Once the user has developed sound prevention and identification 

skills, active use of anti-viral products will help ensure a virus free 


system. These products should be implemented in the following order: 


- identification tools 


* detection or prevention tools 


The identification product will ensure all existing infections are 
identified and removed. Then the virus detection or prevention product can 


be installed to preclude new infections. 
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These measures should be used as follows: 
daily random checks of on-line software as a first line of defense 
against viral infection 


periodic deliberate checks against an off-line protected baseline to 
verify the random verification means 


B; ASSURANCE BUILDING 
While the above measures will provide a strong damage and infection 
prevention program, ditional me are available which could strengthen 


in their use. These assurance 


prevention measures and cover “‘apses’ 
building measures should make use of the inherent security of digitally 
signed software. This means, when preparing software procurement contract 
specifications, organizations should require that vendors certify their 
software is virus free and that it has been digitally signed using a 
"approved product’. 

1. Software Authentication 


Several acknowledged methods currently ex: for simple and 


inexpensive sof’ are authentice2‘ion: 


Realistically, most people will not write protect floppy disks or use 
virus checkers religiously. 


This could be done in conjunction with the National Institute of 
Standarc’ and Technology which is currently developing a standard digital 
signatur: for non-repudiation. Likewise. vendors such as RSA provide 
respected products and act as agent for establishing and maintaining the 
unique digital sig: re applied by each software package sold. 


2 digita signature should be produced on the vendor’s 
developr. nt syste... since it is assumed to be uninfected. This is not 
unrealistic since infections of commercial programs to date have been 
traced to the duplication hardware and not the development system. 
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use Of a public key type signature product such as Sign & Check 
- use of a one-way hash functions such as MD4 


use of multi-function products such as VIRUS-SAFE 
The relative advantages and disadvantages of these methods include: 


One-way hash functions do not require any information to. be kept 
secret. Public key systems require one key be kept secret. 


The public key system would not require creation of substantiating 
documentation. The digital signature is either valid or not. If its not, 
the software is not loaded. One-way hash functions, however, require 
that a substantial paper trail of software’ valid hash codes be 
maintained. Conformity of the hash code generated upon software 
receipt, with the approved hash code maintained in the valid hash 
codes documentation, is then required prior to installation. 


The public key system is much simpler in application than the one- 
way hash function method. 


Public key system licensing costs several hundred dollars per site. 
The one-way hash function code is in the public domain. 


* A multi-feature program could be used in the interim to validate 
software while waiting for vendors to release digitally signed 
software. 


In the form of the digital signature creation algorithm. This is kept 
secret by the vendor. 


This includes all versions and mini-releases. 


For this work, I assume that NAVELEXSECCEN, the Navy’s anti-virus 
command, will create and maintain this paper trail. They will select the 
Navy standard hash function, apply it to all mission support software in 
Navy’s inventory, and release a NAVELEXSECCEN NOTICE detailing the 
software package, version, manufacturer, and hash code. As new software 
is procured or updates received, NAVELEXSECCEN wil] update and reissue 
their NOTICE. Of course, hashing for new software could be required by 
the procurement contact to relieve NAVELEXSECCEN of all but the initial 
effort. 
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C. THE BOTTOM LINE 

A reliable anti-virus product must be robust enough to ensure its own 
integrity, and sophisticated enough to check all executable files without 
exception. 

While evaluating schemes for detecting and preventing viral spread, 
it is important to remember that viruses use the same system capabilities 
available to users. Many products and precautions may be used to slow or 
stop infection spread. Each, however, tends to reduce the computer’s 
utility. As long as we desire flexibility, viru will be able cto exploit 
legitimate system capabilities. As viral programmers become more 
experienced and develop new techniques, distinguishing between legitimate 
and viral activity will become ee increasingly difficult problem. 

This requires more stringent protection and verification schemes. 
Their strength, however, should lie in the verification process and not in 
protection or secrecy of the method. Since most, if not all, of the anti-viral 
products available today have loop holes!, we must shift our reliance from 
these roducts to a computationally secure methodology for absolute virus 
free environments. 

Since viral infection can be traced to the use of infected software’, 
the only efficient way to preclude infection is to prohibit the use of 


tainted programs. The only trustworthy means of prohibition is to require 


Whether it be software interrupt monitoring in the prevention 
product, assumed clean baselines for the detection product, or known 
signature byte strings for the identification product, viruses can exploit 
the weaknesses of even the most sophisticated anti-viral program. 


While the current generation of microcomputer viruses live mostly 
in executable images, this may not necessarily be true in the future. 
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that vendors cooperate with users in a program of software authentication 


using digital signatures. 
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VIII. APPENDICES 


A. EXAMPLES OF DOS VIRAL INFECTION IN THE US 


INFECTED SOFTWARE 


REPORTING LOCATION 


Uniock Masterkey 
SARGON III 
ASYST RTDEMOO2. EXE 


Desktop Fractal 
Design System 


Census Bureau 
1988 Election: City 
& County Data Bank 


Northern Computers 


~snnedy Space Center 
Iceland 
Fort Belvoir 


Various 


Government Printing 
Office/US Census Bureau 


Iceland 
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Jan 9 


Jan 90 


Mar 90 


Vienna 
Cascade (1704) 
Jerusalen-B 


Jerusalem (1813) 


Jerusalemn-B 


Disk Killer 


B. CHRONOLOGY OF A VIRUS AS TOLD BY IT’S AUTHOR 
The author of the Dark Avenger virus has distributed it’s source as 


well as a program, DOCTOR, to remove it. DOCTOR contains the following: 


awe ee ew ewww ewww ew ew ew ee ew ew ew ew eB ee || SB S| MB wewewwwreewe eae ese e228 | Bees een | ew eeweeewee 282 e Be e—e2e ese 2 2 2 = = 


DOCTOR QUICK! Virus Doctor for the Eddie Virus Ver 2.01 10-31-89 
(c) 1988-S9 Dark Avenger. All rights reserved. DOCTOR /? for help 


It may be of interest to you to know that Eddie (aka "Dark Avenger") is the most widespread 
virus in Bulgaria for the time being. However, I have information that Eddie is well-kKnown 
in USA, W. Germany and USSR too, 


I started writing the virus in early September 1988. In those times there were no any viruses 
written in Bulgaria, so I decided to write the first Bulgarian virus. There were some 
different Eddie’s versions: 


VERSION 1.0, 31-OCT-1988 

This version established the most important features of the Eddie virus. Staying resident 
into high end of memory, it was infecting .COM and .EXE files, but only when executing thea. 
INT 13 hadn’t been handled in any way. This version was damaging infected files only, rather 
than infected disks. Also, there weren’t any messages in it (I still wasn’t choosed a name 
for. it). 


VERSION 1.1, 16-DEC-1988 

In December I’ve decided to enhance the virus. This version could infect files during their 
opening. For that reason, a read buffer was allocated in high end of memory, rather than 
using DOS function 48h when needed. The disk was destroyed instead of the infected files. 


VERSION 1.2, 19-DEC-1988 

This added a new feature that causes (for example) compiled programs to be infected at once 
if the virus is resident. Also, the "Eddie lives..." message was added (can you guess why 
exactly "Eddie"?) 


VERSION 1.31, 3-JAN-1989 

This became the most common version of Eddie. A code was added to find the INT 13 rom-vector 
on many popular XT’s and AT’s. Also, other messages were added so its length would be exactly 
1800 bytes. There was a subsequent, 1.32 version (19-JAN-1989), which added self-checksum and 
other interesting features that was abandoned because it was extremely buggy. In early March 
1989 version 1.31 was called into existence and started to live its own life to all 
engineers’ and other suckers’ terror. And, the last 


VERSION 1.4, 17-OCT-1989 

This was a bugfix for version 1.31, and added some interesting new features. Support has been 
added for DOS 2.x and DOS 4.x. For further inforwation about this (the most terrible) 
version, and to learn how to find out a program author by its code, or why viruS-writers are 
still not dead, contact Mr. Vesselin Bontchev (All Rights Reserved). 


So, never say die! Eddie lives on and on and on... Up the irons! 
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C: KNOWN VIRUS INFECTION AND DAMAGE CHARACTERISTICS 
The information below, provided by John McAfee at CVIA, details the 
major characteristics and number of variants, in parenthesis, of the known 


IBM PC compatible virus strains. 


A Infects Fixed Disk Partition Table--+ 
9 Infects Fixed Disk Boot Sector----+ | 
8 Infects Floppy Diskette Boot----+ | ! Directly or Indirectly: 
7 Infects Overlay Files--------- #5 ce! 
6 Infects EXE Files----------- oe ae ee tewn------ Affects Performance 
5 Infects COM fileS--------- a ae eee ae | +Corrupts Programs/Overlays 
4 Infects COMMAND. COM----- o)) a , | #=--Corrupts File Linkages 
3 Install Self in Memory+ | | } {| {| i 3 , | | +---Corrupts Data Files 
2 Self-Encryption----- PP Guei ae kek 1 | ft -+Conme s Boot Sector 
1 STEALTH Techniques+ {| {| {| |} | ij { ¢ 5 es a -Form.ts Disk 
a a eee cece roe 
Vit yA os noes ‘age mecane « Increase in 
ie co eee reotoeeoet SAnfected Program 
12 3°4°5"6 78°99 A 12345 6 Size 
| | i] i] i] | | i] | i] i] $ i] 4 i] § | 
i] | i ] i] i] 4 i] i] i] i] i i] 4 ' | 4 
Virus VVVVVVVYV VV VVVVVYV Vv 
AzuSa irae Kes nea > a pa ae ame oo N/A 
Lazy ok OX ae « Aes XM «@ @ wars 720 
V-555 eet ele a? lee Ske ae eT “xX xX We. 555 
Phantom ae, a, as ee 5 Ge Se erm eee 2253 
V-299 er Le ee 299 
Cancer ina 6. ee oes x x x ° 1480 
1575/1591 .) y MSG ‘ MX 6 os vary 
USSR 492 Me ee oy ae Mi cMo aee ae 2 492 
USSR 1049 a: pier SG ae 6? es MMe ss 1049 
Skism eee. Xe aid Xe ee See 556i as 1815 
Holocaust a MeN) eh Es ae 4 X4388 3784 
Stone-90 a oe ee x Xone «en 961 
903 . «+ ix MEX . ae aeee xe 4 ee 903 
Dir-Vir Ks KX 020s © a & % “Xs Xs G 691 
Hybrid a ee ae > ee MM a8 1306 
IKV528 OO ee = xX soe. 528 
Iraqi Warrior ee co Gar ere MUX Kk ss rit 
Little Pieces oan Ke eg Dek ie 1374 
Saddam . o 0-0 KG. 2 xox XX X 2 919 
Monxla-B a > ot ae eee ae ee CK eis ois 535 
Plague Pe aed? Oe Sere NS ts ee Overwrites 
Polish 217 Per Soe A Sige eek. ee al? 
Sentinel Pe > Oe. ae a eee X XY kos, 4625 
Swiss 143 S ©. go ee 5 ae ee ae a 143 
USSR-311 ecg ew RR eee. 8 ee pees 321 
Voronezh ~xxxxx xX ‘ear MMe Xa 1600 
V-961 -»* XX =X. ‘ Xx x eee as 961 
USSR-830 ee ee yey ee Diese gee 830 
USSR-529 Pepe > Cee a eee eee MoM eaves. “sles 529 
USSR-516 eee ee cs MoM? ee es 516 
USSR-2144 XMM XX NX. : xxXxXxXx. . 2144 
USSR-1049 i oe Le tee ee. Us NOG ie nen 1049 
USSR (3) a Mie a we eH as Mees 575 
Tiny-133 Ee er oa. Caer ee ne oe Mee! os 133 
Sverdlov ree o> os oe ee ‘ MX 60. 4% 1962 
Label io He SS ee a ees ah? ex eo ae ae Overwrites 
Kukaturbo a. o> Saree ‘ or ee Over» :tes 
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1704 
2086 
12380 
701 
1704 
n/a 
1704 
n/a 
n/a 
n/a 
648 


Overwrites 


648 
1808 
n/a 
SZ 
1808 


1488 
897 
n/a 


All Others - Length in bytes a file wiil increase when infected. 


Characteristics: 
x - Yes 
r) = No 
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D. ANTI-VIRAL PRODUCT MINIMUM CAPABILITIES LIST 

The minimum capabilities in the sections below are recommended by 
John McAfee at CVIA. They can be used to provide a rough cut on 
prospective anti-viral products. Acceptable products should then be 
evaluated using the testing criteria in Appendix E. 


1. Infection Prevention Products 


* Differentiate between activities initi 1 by the user and activities carried out 
autonomously by »rograms. Users may dele or update program files or operating system 
segments. An application program, on .@ other hand, should not, under normal 


circumstances, modify another application program, an operating system program, or the 
system’s boot sector. This is indicative of viral activity; 


° Provide few false positives, or false alarms. Users become habituated to frequent false 
alarms and tend to overlook a valid virus warning when it does occur; 


* Run with other memory resident programs. Infection prevention programs are all memory 
resident and they modify a large number of software interrupts. This gives such 
programs a propensity for crashing or hanging the system when running concurrently with 
other memory resident programs; 


* Protect against modifications to all executable data, including: the system’s boot 
sector, device drivers, operating system modules, including hidden file programs, and 
all application programs; 


* Provide an easily accessible enable/disable switch. Many instances will occur where the 
checking process will need to be temporarily suspended; 


* Provide the ability to selectively protect or ignore specific programs or specific 
areas of the system. This will reduce the number of false alarms when running programs 
which violate the "rules" imposed by the product; 


° Provide the ability to freeze virus activity when it is detected, and pre: ?-nt the 
illegal access from continuing. This is mandatory to prevent the virus from -ecting 
the systen; 


* Run without noticeably degrading system performance. Memory resident programs have a 
tendency to increase system overhead and thus slow down the system. A well designed 
product should cause no more than a 5% degradation in system performance; 


* Monitor and protect all attached read/write devices. All attached devices that can be 
written to are potential virus targets. The prevention product should protect all such 
devices; and, 


* Selectively prevent interrupt level I/O and non-standard calls for I/O service 


(interrupt level requests). Since doing so increases the false alarm rate, the user 
should have the choice of allowing or disallowing such calls. 


2. Infection Detection Products 


* Detect characteristic viral modifications to execut. le data, including: the system’s 
boot sector, system device drivers, operating syste modules, including hidden file 
programs, and all application programs; 
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Allow the user to selectively exclude specific programs or areas of storage from 
checking. This will allow programs or directories that undergo frequent Change to avoid 
causing error messages; 


Perform global check functions ina timely fashion. If the check function is executed 
at boot time, for example, it should add no more than 10 seconds to the boot sequence 
for each 50 programs on the disk that must be checked; 


Provide automatic checking. The check function should execute at least each time the 
system 1S powered on or re-booted. Some systems provide a clock function so that the 


system can be checked automatically at user specified time intervals; 


Stop the system, provide a visual and audible warning, and wait for user directions if 
a potential virus is detected; and, 


Display the names of all programs or system areas that have become infected. 


3. Infection Identification Products 


Identify and remove multiple virus strains; 


Provide information to allow the user to determine the diagnosis accuracy. Modified 
viruses Can sometimes only be detected by cross’ referencing many different 
characteristics. The product should provide the degree of certainty, or other 
information that can be used to determine a course of action, for anv questionable 
Virus; 


Identify and report infected system areas and the extent of infection; 

Inform the user of the anticipated degree of success for removai. Depending on the 
length of time since infection, removal may or may not be possible. The product should 
inform the user of possible options including automatic removal or erasure of the 


affected system element; 


Scan and remove infection from all attached devices including floppies, fixed and 
removable hard disks, and tape devices; 


Automatically scan all subdirectories; 


Flag all system areas where removal was incomplete. These areas must be manually dealt 
with after the program finishes; and, 


Prevent self infection during the identification and removal process. An infected 
identification product will run the risk of infecting every system on which it 1s used. 
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E. ANTI-VIRAL PRODUCT EVALUATiON PROCEDURES 

The test procedures in the sections below are recommended by John 
McAfee at CVIA. While not scientifically rigid, they will provide additional 
performance information not otherwise obtainable. Any proditet Jena 
performs well in testing will provide some degree of real protection. 


1. Infection Prevention Products 


* Install the antiviral product; 


* Test the product’s ability to protec* teneral executable programs from being modified. 
Create a temporary subdirectory and ‘ your word processor into it. Create two output 
text files named TEST, one witha .! extension and the other with a .COM extension. 
Then attempt to update the file usinz .-ne word processor. The antiviral program should 
flag both the creation and the update as a potential infection. Repeat these steps for 
the system files (IBMBIO.COM, IBMDOS.COM, and COMMAND.COM) as well as all device 
drivers. Repeat each of these steps using a floppy diskette as the output device, 
instead of the hard disk subdirectory. The same results should occur. 


* Test the product’s ability to prevent interrupt level I[/0. First copy the FORMAT 
routine to a file named TEST.COM. Run TEST and format a floppy diskette inthe A or B 
drive. The antiviral program should prevent the format and flag the attempt. 


° Test the use of operating system commands. User commands are frequently, and 
erroneously, flagged by antiviral products when they instigate operations that mimic 
virus activities. Using COPY, DELETE and RENAME commands, copy an executable progran 
into a different directory, rename it to another EXE or COM file name, and then delete 
it. None of the three operations should be flagged by the antiviral program. 


* Verify that the above functions would be stopped if performed by a program, rather than 
by the user. Using any application utility program that has coov, rename and delete 
functions , repeat the above series of steps. The antiviral pr’ n should prevent and 
flag all three attempts as potential viral activities. 


°* Test self modification. Many programs modify their own executable modules a _ some 
point. The antiviral program should not flag or prevent this. To test this, cop. your 
word processor executable module to a backup file. Then run the word processor, create 
a dummy document, and then save it to the name of the executable word processor aodule. 
The antiviral program should allow the modification. After this test, copy the saved 
version of the program back to its original name. 


* Test for detection of boot sector modification. Using any utility that allows reading 
and writing the boot sector, read the boot sector and write down the contents of the 
first byte. Change the first byte to 00 and a*~empt to write the sector back to disk. 
The product should prevent the attempt. If ° + product fails, replace the original 
contents of the first byte and re-write the boot sector. The re-write should be 
performed prior to shutting down or re-booting the systen. 


° Test for memory residence. Many viruses modify the original structure of programs so 
that they remain meaory resident after they terminate. The antiviral product should 
detect any attempt to remain resident. To test this feature, merely take any normally 
memory resident program, such as SIDEKICK or CACHE, and rename it to the file TEST.COM 
(or .EXE, depending on the program). Run TEST. The product should catch the program and 
display a warning message. 
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2. Infection Detection Products 


Test for detection of boot sector replacement. Using a disk utility, create a safe 
unique boot sector by blanking out the "Boot Failure" message. Then install the 
detection product you wish to test. Next, replace the entire boot sector using the SYS 
command. Then execute the check function of the product you are testing. The product 
should warn that the new boot sector 1s a replacement, 


Test for detection of boot modification. Next, re-install the detection product. Then 
modify the boot sector randomly using the disk utility. Run the check routine. The 
product should warn that the boot sector has been modified. (When finished with this 
step, perform the SYS command again, or use the disk utility to return the boot sector 
to its original state). 


Test for detection of program deletion. Copy a number of COM and EXE files to a 
temporary directory and then delete the originals. Run the detection check function. 
The product should identify each of the missing programs. 


Test for detection of program modification. Copy the programs back from the temporary 
directory to their original directories. Using your disk utilitv, modify the first byte 
of each of the COM programs. Modify the entire first 500 bytes of the EXE programs. 
Run the check program. Each modification Should be detected. At this point you should 
replace each of the modified programs from the original programs stored in the 
temporary directory. 


Test for detection of program replacement. Replace an application program with the 
original from the distribution diskette. Then modify the program as above. The check 
function should still catch the modification. 


Test for detection of system modification. Using a disk utility, copy IBMBIO.COM, 
IBMDOS.COM, and COMMAND.COM to backup files. Randomly modify each of the original 
files, using the disk utility, by changing only one byte in each. Run the check routine 
to determine that the modifications have been detected. Perform this step multiple 
times with different modifications. 


3. Infection Identification Products 


The first steps are to isolate the infected system from all others, and to acquire 
clean, original copies of the infected programs. Make working copies of these 
uninfected programs onto separate floppy diskettes, one sample program per diskette. 


Insert each floppy in turn into the infected system and run each Sample program. This, 
in most cases, will cause the diskette, or the program, to become infected. 


Using a disk utility, doa binary compare of the infected diskette to the backup copy. 
If an infection has occurred, the diskettes will differ. Separate all working copy 
diskettes that have been modified by the virus and label them as infected. 


Now run the identification program against each of the infected floppies. Do this on 
a Clean, uninfected system. The program should identify the infection on each diskette. 
Next cause the program to attempt removal. Run each floppy in turn through the removal 
cycle. The program should remove all of the infections. 


To test that the removal worked, take the infected (and now hopefully disinfected) 
diskettes and again do a binary compare against the original backup diskettes. There 
should be no discrepancy. 


If the program has passed the above tests, it is clearly able to identify and, at least 
in test disks, remove the infection. At this point you should test its operation on the 
infected system. To do this, first make a backup copy of the product. Then load the 
identification program into the infected system and begin the identification and 
disinfection process. 
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* On completion of the operation, performa disk compare of the working disk against th» 
original product disk. There should be no differences. 
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F. ANTI-VIRAL SOFTWARE 
The following anti-viral products are available commercially: 


1. Infection Prevention Systems 


Product Vendor Phone 
ACE System Security Dynamics (617) 547-7820 
Data Physician Digital Dispatch (612) 571-7400 
1580 Rice Creek Road 
Minneapolis, MN 55432 
Disk Defender Director Technologies (3127) -49 2P=2334 


Flu-shott Software Concepts Design (212) 889 6138 
594 Third Avenue 

New York, NY 10016 
McAfee Associates 

4423 Cheeney Street 
Santa Clara, CA 95054 
Box 7180 

IS-127 Reykjavik 
Iceland 

10201 Torre Avenue 
Cupertino, CA 95014 
Lasertrieve 

395 Main Street 
Metuchen, NJ 


FShield (108) 988-3832 


F-PROT 


Norton AntiVirus (800) 343-4714 


VirALARM 2000 (201) 906-1901 


08840 


Virus Implant Protector Leemah Datacom Security (415) 786-0790 
3948 Trust Way 
Hayward, CA 94545 
2. Infection Detection Systems 
Product Vendor Phone 
Sentry McAfee Associates (408) 988 3832 
Tracer McAfee Associates (408) 988-3832 
Vaccinate Sophco (800) 922-3001 
P.O. Box 7430 
Boulder, CO 80306 
Virus-Pro International Security (212) 288-3101 
Technologies 
Virus Safe Enigma Logic Inc. (415) 827+5707 
2151 Salvio Street, #301 
Concord, CA 94565 USA 
3. Infection Identification Systems 
Product Vendor Phone 
Detect McAfee Associates (408) 988-3832 
Scan Virus IBM (800) 426-2468 
Viruscan McAfee Associates (408) 988-3832 
V-Finder WallyWare (408) 275-6358 
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G. MD4 LISTING 


/*« 

. oP kP SPS SSS SES SESE SSS SS SSSSSSSLE SS SSSPSSOSS SS SCeSeCeePCaRSSPaSSS SPEARS LESS ee Se S ® 5 
«x md4.c -- Implementation of MD4 Message Digest Algorithm ** 
«x Updated: 2/16/90 by Ronald L. Rivest x 


«« (C) 1990 RSA Data Security, Inc. 
KKK KEK ERE KKK KEK KEK KEE KKK KK EE EEE KEE KK EE KEKE KEKE CK EEK EE KECK EK 


a 

/* 

**« To use MD4: 

mx -- Include md4.h in your program 


«x -- Declare MDstruct MD to hold the state of the digest computation. 
«x -~- Initialize MD using MDbegin(&MD) 


* x -- For each full block (64 bytes) X you wish to process, call 

** MDupdate(&MD,X,512) 

ax (512 1s the number of bits ina full block.) 

Kx -- For the last block (less than 64 bytes) you wish ¢ “cess, 
«x MDupdate(&MD,X,n) 

‘x where n is the number of bits in the partial block. partial 
** block terminates the computation, so every MD computation should 
«x terminate by processing a partial block, even if it has n= 0O. 
«x -- Message digest is available in MD.buffer[0} ... MD.buffer[3}. 
sone (Least-significant byte of each word should be output first.) 
«x -- You can print out the digest using MDprint(&MD) 

7 ~ 


/* Implementation notes: 

** This implementation assumes that ints are 32-bit quantities. 

** If the machine stores the least-significant byte of an int in the 
** least-addressed byte (VAX and 8086), then LOWBYTEFIRST should be 

** set to TRUE. Otherwise (eg., SUNS), LOWBYTEFIRST should be set to 
** FALSE. Note that on machines with LOWBYTEFIRST FALSE the routine 
** MDupdate has a side-effect on its input array (the order of bytes 
** jm each word are reversed). If undesired, a MDreverse(X) call can 
** reverse the bytes of X back into order after each call to MDupdate. 


#tdefine TRUE 1 
define FALSE 0 
define LOWBYTEFIRST TRUE 


/* Compile-time includes 


a 


finclude <stdio.h> 
include "md4.h" 


/* Compile-time declarations of MD4 ‘‘magic constants’’. 


| 


#define I0 0x67452301 /* Initial values for MD buffer */ 
#define Il Oxefcdab89 

#define I2 Ox98badcfe 

#define I3 0x10325476 

tdefine C2 013240474631 /* round 2 constant = sqrt(2) in octal */ 
tdefine C3 015666365641 /* round 3 constant = sqrt(3) in octal */ 
/* C2 and C3 are from Knuth, The Art of Programming, Volume 2 

**x (Seminumerical Algorithms), Second Edition (1981), Addison-Wesley. 
** Table 2, page 660. 

=) 

define fsl 3 /* round 1 shift amounts */ 

#define fs2 7 

#tdefine fs3 1l 
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define fs4 19 

tdefine gsl 3 /* round 2 shift amounts */ 
tdefine gs2 5 

tdefine gs3 9 

tdefine gs4 13 

tdefine hsl 3 {* round 3 shift amounts *€*/ 
gdefine hs2 

¢define hs3 1l 

define hs 15 


/* Compile-time macro declarations for MD4. 

** Note: The ‘‘rot’’ operator uses the variable ‘'tmp’'. 

ke Tt assumes tmp is declared as unsigned int, so that the >> 

«+ operator will shift in zeros rather than extending the sign bit. 


a! 

saefine £(X,.1¥,2 9 CONEY) © LE XESS) 

tdefine g(X,Y,2Z) ((XRY) | (X&Z) 1 (YEZ)) 

tdefine h(X,Y,Z) CX° 723 

#define rot(xX,S) (tmp=X,(tmp<<S) ; (tmp>>(32-S))) 
gdefine ff(A,B,C,D,i,s) A = -routceal* £(3,C,D)- + X{1])5s) 
#define gg(A,B,C,D,1,8S) AS = SPOCUCA-s* S08 Diet. KP eZ) S) 
gdefine hh(A,B,C,D,1i,s) Ae: SroucCaAs + NCB, C,D)yet X[2 > 4.03) \S) 


{* MDprint(™MDp) 
** Print message digest buffer MDp as 32 hexadecimal digits. 
** Order is low-order byte of buffer{0] to high-order byte of buffer[3]. 
**« Each byte is printed with high-order hexadecimal digit first. 
** This 1S a user-callable routine. 
ih | 
void 
MDprint (MDp) 
MDptr MDp; 
Ferme, 33 

for (1-=0°-1<4;1++4) 

for (j=0; }<32; j=j+8) 
printf("%02x",(MDp->buffer[i])>>}) & OxPF); 

} 


/* MDbegin(MDp) 
** Initialize message digest buffer MDp. 
** This is a user-callable routine. 
a 
void 
MDbegin(MDp) 
MDptr MDp,; 
erat. 1; 
MDp->buffer[0} 
MDp->buffer[1} ip 
MDp-> buffer[2} Lz; 
MDp->buffer[3} = 13; 
for (1-0;1<8;i++) MDp->count[i] = 0; 
MDp->done = 0; 


10; 


} 


/* MDreverse(X) 
** Reverse the byte-ordering of every int in X. 
** Assumes X is an array of 16 ints. 
*x* The macro revx reverses the byte-ordering of the next word of X. 
x 

/ 
#tdefine revx { t = (*X «<< 16) } (*X >> 16); \ 

*X++ = ((t & OxFFOOFFOO) >> 8) | ((t & OXOOFFOOFF) << 8); } 

MDreverse(X) 
unsigned long int *X; 
{ register unsigned long int t; 

revx; revx; revx; revx; revx; revx; revx; revx; 

revx; revx; revx; revx; revx,; revx; revx; revx,; 


} 
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/* MDblock(MDp,X) 
tx Update message digest buffer MDp->buffer using 16-word data block X. 
*©* Assumes all 16 words of X are full of data. 
*«* Does not update MDp->count. 
*«* This routine is not user-callable. 
= 
static void 
MDhblLock(MDp,X) 
MDptr “Dp; 
unsigned long int *X; 
{ 
register unsiened long int tmp, A, B, C, D; 
#if LOWBYTEFIRST == FALSE 
MDreverse(X); 
tendif 
A = “Dp->buffer[0]; 
B = MDp->buffer[1]; 
C = MDp->buffer[2]; 
D = MDp->buffer[3]; 
/* Update the message digest buffer */ 


ff(A , B,C,D, O, fsl); /* Round 1 */ 
f£(D = Au 8 °C. ele sc 
fFCC 3 Di bA = BS Vee tso) 
ff CB° 5) Cy. “DY 5 Ag eo este 
ffiA ,- B,C. Dy 4) ats). 
ffiD , A, B ; "C1 5 .etser 
ff(cC , D, A, By} 6 tsa. 
£fCB :: C .<D° ,-A A) 7 ees a ~ 
f(A, B jC 20D, 9S os fs). 
f£(De, Av; Bo 463) 89 £52): 
fF(C -., D, A,B, 10 ~ fsa); 
ff£(B « 'C, DD, Ay, Tl wertes 
ff(A.,. Bo C.D el Zea 
ff£( DA, B.,- Cs. 13 ees2); 
f£(C , DD , -AvaoB | dteetss): 
ff(ao, C , DD, A yi i1S Beets4). 
gg(A , B,C ,0D, O , gsl); /* Round 2 */ 
ga(D, Ay, 8°) © eee ese). 
gg(C .. D , A, Boy esp eso, 
gg(B ,C,D,A4A, 12 , gs4); 
RGCAL FOB, © 2D lees); 
gag(D , A,B,C, 5, gs2); 
gg(C ,D,A,B, 9, gs3); 
geg(B ,C ,D,A,13 , gs4); 
gg(A ,B,C,D, 2, gsi); 
geg(D , A,B,C, 6&6, gs2); 
a@g(C ;-D ; A 4B, 10, 283): 
eg(B , C , D7 A, 14° e549); 
gg(A, B , Cy, D , 3 , gal); 
gg(iD , A, B,C, 7, gs2); 
gg(C ,D,A,8B, 11 , gs3); 
gg(B ,C,D,A4A, 15 , gs4); 
hh(A , B,C ,D=, OO, hsl); /* Round 3 */ 
hh(D , A,B,C, 8 , hs2); 
hh(c , D, A,B, 4, hs3); 
nhhcB, Cc , D, A, 12 , hs4): 
hh(A , B,C,D, 2, hsil); 
hh(iD , A,B,C, 10, hs2); 
hhic , D, A,B, 6, hs3); 
hh(B , C,D,4, 14 , hs4); 
hh(A , B,C,D, 1, hsl); 
hh(D, A, B 4-6", 9°; hsz); 
hht(c), Di» € ,-B ;, 5 , hs3); 
hhiBs, cc , D, A , 13 , hed) 
hh(A , B,C ,OD, 3, hsl); 
Hicor A+, B , C’5. 11, Ns2); 
hh(G 4D , A 4B % 7 4) hss); 
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firepe, © 4: Deer A, 915), nst); 

MDp->buffer[0] += A 

“MDp->buffer[1l] += B 

MDp->buffer(|Z] += C; 

MDp->buffer[3] += D 
} 


/* MDupdate(“Dp,X,count ) 


*r Tnput: MDp -- an MDptr 
ie X -- a pointer to an array of unsiened characters. 
«4 count -- the number of bits of X to uSe. 


ns (if not multiple of S, uses high bits of last bvte.) 
‘* Update 4Dp using the number of bits of X given bv count. 

‘* This 1s the basic input routine for an MD4 user. 

‘® The routine completes the MD computation when count <« 512, so 

‘* every 4D computation should end with one call to “MDupdate with a 


Kt count less than 312. <A call with count O will be ignored if the 

re MD has already been terminated (done!-0), so an extra call with count 
** 0 can be given as a ‘courtesy close’ to force termination if desired. 
Mf 

void 

MDupdate(“Dp,X,count ) 

MDptr MDp; 


unsigned char *X; 
unsigned int count; 
{ unsigned long int 1, tmp, bit, byte, mask; 
unsigned char XX[64]; 
unsigned char *‘p, 
/* return with no error if this 1s a courtesy close with count 
** zero and MDp->done is true. 
* 
if (count =- O && MDp->done) return; 
/* check to see if MD 1s already done and report error */ 
if (MDp->done) { printf("\nError: MDupdate MD already done."); return; 
/* Add count to MDp->count */ 
tmp = count; 
p = MDp->count; 
while (tmp) 
( tmp += *p; 
*p++ = tmp; 
tmp = tmp >> 8; 
} 
/* Process data */ 
if Ceount == 312) 
{ {/* Full block of data to handle «/ 
MDblock(MDp, (unsigned long int *)X); 


} 
else if (count > 512) /* Check for count too large */ 
{ printf 
("\nError: MDupdate called with illegal count value %d.",count); 
return, 
} 


else /* partial block -- must be last block so finish up */ 
{ /* Find out how many bytes and residual bits there are */ 
byte = count >> 3; 
bit = count & 7; 
/* Copy X into XX since we need to modify it */ 
for (i=0;i<=byte;itt) XX[ij} = X{1]; 
for (i=byte+t1;i<64;it++) XX[i]} = 0; 
/* Add padding ’1’ bit and low-order zeros in last byte */ 
mask = 1 << (7 - bit); 
XX[ byte] = (XX[byte] | mask) & ~( mask - 1); 
/* If room for bit count, finish up with this block */ 
if (byte <= 55) 
{ for (i120;1<«8;1++) XX[56+i] = MDp->count[i]; 
MDblock(MDp,(unsigned long int *)XX); 
} 


else /* need to do two blocks to finish up */ 
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/* 


«6 


a) 


MDblock(MDp,(unsigned long int *)XX); 

for (12071<456;3++) XX[a} 9-0: 

for (1=0;1<8;i++) XX(56+1]}] = MDp->count{[1]; 
MDblock(MDp, (unsigned long int *)XX); 


/* Set flag saying we’re done with MD computation ©€/ 
MDp->done = 1; 
} 


End of md4+.c 
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